Managing encryption keys in a computer system

ABSTRACT

A method and apparatus is disclosed for managing encryption keys in a computer system in which in response to the change of a system key the old key and new key are both maintained for subsequent use.

BACKGROUND

1. Field of Invention

The present invention relates to managing encryption keys in a computersystem.

2. Background of the Invention

Computer systems are commonly implemented as virtual machines. A virtualmachine (VM) is a software implementation of a computer that provides anoperating system or executes application programs as if it were aphysical machine. VMs are commonly provided on a physical machine by avirtual machine environment (VME) application program, which provides auser interface for managing the provided VMs.

As with any computer system some of the associated data may need to bestored securely and is thus encrypted when not in use. Encryption anddecryption is performed using an encryption key. Access to theencryption key is controlled so as to be limited to predetermined usersor processes. In a VME, system encryption keys may be provided forencrypting data within the VME such as data in any of the VMs or the VMsystem data itself. System encryption keys may be changed by any userwith suitable security access. The change of the system encryption keyin a VME commonly triggers a process of re-encryption of all encrypteddata in the VME with the new system key. Re-encryption using the newsystem key is therefore only possible when data is locked so that itcannot be accessed, that is, the encrypted data is guaranteed not to bein use.

VMs may be migrated between VMEs on different physical computers via anetwork connection connecting the relevant source and target computers.During migrations secure data is encrypted using the system encryptionkey of the VME on the source computer before being communicated to thetarget machine and decrypted using the system encryption key of the VMEon the target computer.

In order for the migration to be successful, the system encryption keymust be the same at both the source and target computers. Therefore,system key changes during migration or prior to decryption of migratedencrypted data are not allowed. In other words, migrations and keychanges are not allowed to co-exist. Since migrations can be longprocesses, the inability for these processes to be performedconcurrently is a significant problem in such computer systems.

SUMMARY

An embodiment of the invention provides a method for managing encryptionkeys in a computer system, the method comprising the steps of:

-   -   storing a first key for encrypting data for a selected domain;    -   storing a second key for the domain in addition to the first key        in response to a key change for the domain; and    -   providing the first key or the second key in response to a        request for an encryption key for the domain.

One of the keys may be provided in response to a first request and theother the key is provided in response to a subsequent associated requestfor an encryption key for the domain. Keys may be provided in responseto any set of one or more associated requests in the reverse order towhich the keys were created. All the keys may be provided in response tothe request. Keys may be maintained up to a predetermined maximum numberafter which the oldest key is discarded in response to the storing of anew key. A record of key usage may be maintained and the oldest unusedkey is discarded in response to the storing of a new key.

The keys may be maintained in a key history for the domain. The keyhistory may comprise a list of the keys ranked in the order in which thekeys were created. The domain may be a physical computer system. Thedomain may comprise a virtual machine comprising data encrypted using aselected one of the keys. Migration of the virtual machine to a targetdomain may only be performed if the selected key is available in thetarget domain. The keys may be ranked and the ranking of the selectedkey for the virtual machine is provided to the target domain foridentification of the key in the target domain. The ranking may bearranged for use in the target domain for identifying the selected keyfrom a set of keys for the target domain for decryption of the encrypteddata. If the ranking fails to identify the selected key then successivekeys from the set of keys for the target domain may be checked toidentify the selected key.

Another embodiment provides apparatus for managing encryption keys in acomputer system, the apparatus being operable to:

-   -   store a first key for encrypting data for a selected domain;    -   store a second key for the domain in addition to the first key        in response to a key change for the domain; and    -   to provide the first key or the second key in response to a        request for an encryption key for the domain.

A further embodiment provides a computer program stored on a computerreadable medium and loadable into the internal memory of a computer,comprising software code portions arranged, when the program is run on acomputer, for performing a method for managing encryption keys in acomputer system, the method comprising the steps of:

-   -   storing a first key for encrypting data for a selected domain;    -   storing a second key for the domain in addition to the first key        in response to a key change for the domain; and    -   providing the first key or the second key in response to a        request for an encryption key for the domain.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention will now be described, by way of exampleonly, with reference to the accompanying drawings in which:

FIG. 1 is a schematic illustration of a networked computer systemcomprising computers provided with virtual machine environments (VMEs);

FIG. 2 is a schematic illustration of components of the virtual machineenvironment (VME) on one of the computers in the system of FIG. 1;

FIG. 3 is a table illustrating a set of encryption keys in the VMEs ofFIG. 1;

FIG. 4 is a flow chart illustrating the processing performed in one ofthe VMEs when changing an encryption key in the computer system of FIG.1; and

FIGS. 5 and 6 are flow charts illustrating the processing performed inthe VMEs of FIG. 1 when migrating virtual machines between computers.

DETAILED DESCRIPTION

With reference to FIG. 1, a computer system 101 comprises a first andsecond computers 102, 103 interconnected via a network 104. Each of thecomputers 102, 103 is provided with an operating system 105, whichprovides a platform for running one or more application programs. In thepresent embodiment, each of the computers 102, 103 is loaded with avirtual machine environment (VME) application program 106, in the formof a hypervisor, arranged to provide one or more virtual machines (VMs)on each of the computers 102, 103.

With reference to FIG. 2, the VME 106 comprises a VME user interface(VME UI) module 201 and a VM manager module 202. The VME UI 201 isarranged to provide user control of the VME 106. The VM manager module202 is arranged to manage the creation and operation of one or more VMs203, 204 205. In the present embodiment, two of the VMs (VM1, VM2) 203,204 comprise secure data 206. The VM manager module 202 comprises a VMmigration manager 207, a migration inventory 208, a system key history209 and two instances of a secure data manager module 210, 211 eachcorresponding to one of the VMs (VM1, VM2) 203, 204 that comprise securedata 206.

The VM migration manager 207 is operable in response to an instructionfrom a user via the VME UI 201 to migrate a selected one of the VMs 203,204, 205 from its source domain, that is, the VME 106 on the firstcomputer 102 to a target domain, such as the VME 106 on the secondcomputer 103. In response to such an instruction, the VM migrationmanager 207 builds the migration inventory 208 identifying the data andresources relevant to the VM to be migrated to the target domain. The VMmigration manager 207 is also arranged to ensure that the target domaincomprises the necessary resources to support the migrated VM.

The system key history 209 is maintained by the VME 106 and comprisesencryption keys for encrypting and decrypting the secure data 206. Inthe present embodiment, when a domain encryption key is changed inresponse to a user input, both the new and the old keys are maintainedin the system key history 209. Thus, a predetermined number of old keysremain available for encrypting and decrypting the secure data 206 evenonce a new encryption key has been provided. The system key history 209will be described further below with reference to FIG. 3.

The secure data manager modules 210, 211 are arranged to provide accessto the secure data 206 for permitted processes. The secure data managermodules 210, 211 receive requests to access the secure data 206 and, ifthe requesting process is authorised, decrypt the secure data 206 usinga key from the system key history 209 and provide the decrypted securedata 206 to the requestor. In the present embodiment, the VM migrationmanager 207 is permitted to access the secure data 206 to enable it tomigrate the corresponding VMs 203, 204. A secure data manager module210, 211 is provided for each of the VMs 203, 204 that comprise securedata 206. No secure data manager module is provided for the third VM 205that does not comprise secure data.

With reference to FIG. 3, in the present embodiment, the system keyhistory 209 comprises an ordered list of entries, each entry storing a128-bit encryption key 301 and a key hash 302. The key hash 302 isproduced from the corresponding encryption key 301 by the SHA-1 hashingalgorithm. Each entry further comprises a key number 303, which, in thepresent embodiment, indicates the relative position of the entry in thesystem key history 209. In the present embodiment, the entries arestored in the system key history 209 in the order in which they werecreated. The first encryption key 301 is assigned key number 1 and foreach subsequent key the corresponding key number 303 is incremented. Inother words, the newest key 301 will have the highest key number 303. Inthe present embodiment, the system key history 209 has a maximum ofthree entries. Thus, once the system key history 209 comprises threeentries, each subsequent key change results in the oldest entry beingremoved from the system key history 209.

In the present embodiment, the key hash 303 is used by the VM migrationmanager 207 to check that the target domain of any given migration hasthe same encryption key available. The key hash 303 enables thecorresponding encryption key to be identified without having to exposethe encryption key 301 itself to non-secure environment such as thenetwork 104.

In the present embodiment, the key number 303 is used by the VMmigration manager 207 when performing a migration to indicate to thetarget VME 106 which entry in the source system key history 209 was usedto encrypt the relevant secure data 206. If the source and target systemkey histories 209 correspond then the use of the key number 303 asdescribed avoids the target VME 106 having to perform a search of itssystem key history for the correct encryption key to decrypt thereceived secure data 206.

The processing performed by the VME 106 when changing encryption keysfor the relevant system or domain will now be described further withreference to the flow chart of FIG. 4. Processing is initiated at step401 in response to a user command and processing moves to step 402. Atstep 402 the user inputs the new key phrase and processing moves to step403. At step 403 the new key is created from the input key phrase inaccordance with an associated algorithm and processing moves to step404. At step 404 the new key is inserted at the first free entry. If theencryption key history 209 was full prior to the arrival of the new keythe oldest key having key number 1 is deleted and the remaining entriesshifted to provide space for the new key. Processing then moves to step405 where data encrypted under any old key, that is, any key in theencryption key history 209 apart from the newly inserted key, is markedfor re-encryption with the new key. Re-encryption of such data isperformed by an existing background process in VME 106 and takes placewhen the relevant data is not in use. Processing then moves to step 406and ends.

The processing performed by a VME 106 when migrating a VM from a sourcedomain to a target domain will now be described further with referenceto the flow chart of FIG. 5. Processing is initiated at step 501 inresponse to a user instruction and processing moves to step 502. At step502 the VM to be migrated is identified and a migration inventory 208compiled and processing moves to step 503. At step 503 the migrationinventory 208 is used to identify secure data 206 in the VM andprocessing moves to step 504. At step 504 the encryption key 301 for thesecure data is identified, the corresponding key hash 302 retrieved fromthe system key history 209 which is then used to request if the sameencryption key is present in the target VME 106 key history. Processingthen moves to step 505 where if the target 106 VME 106 indicates thatthe key 301 is present then processing moves to step 506. At step 506the migration of the VM is initiated including the encrypted secure dataaccompanied by the key number 303 corresponding to its encryption key301 and processing moves to step 507. At step 507 if the migration issuccessful then processing moves to step 508 and ends. If at step 508the migration has failed then processing moves to step 509 where the VMis resumed or reinstated on the source VME 106 with processing thenmoving to step 508 and ending. If at step 505 the target VME 106indicates that the key 301 is not present processing moves to step 510to report a key error and then moves to step 508 and ends.

The processing performed by a VME 106 in a target domain when receivinga migrating VM from a source domain will now be described further withreference to the flow chart of FIG. 6. Processing is initiated at step601 in response to the receipt of a migration request from a targetdomain and processing moves to step 602. At step 602 the requiredresources indicated in the migration request are identified in thetarget domain and processing moves to step 603. If at step 603 therelevant resources are identified as available then processing moves tostep 604. At step 604 a key hash 302 is received and checked against thesystem key history 209 and processing moves to step 605. If at step 605the key hash 302 is present in the system key history 209 this isreported to the source VME 106 and processing moves to step 606. At step606 the migrating VM is received and set up in the target domain andprocessing moves to step 607. At step 607 the key number 303 providedwith the migrating VM is used to index the domain system key history 209to identify a suitable decryption key for the secure data 206 in themigrating VM and processing then moves to step 608. At step 608 if thedecryption with the key indexed by the provided key number 303 wassuccessful then processing moves to step 609. At step 609 if the key wasan old key, then processing moves to step 610. At step 610 the decrypteddata is marked for re-encryption with the latest system key andprocessing moves to step 611 and ends.

If at step 609 if the key was the latest key then processing moves tostep 611 and ends. If at step 608 the decryption with the key 301indexed by the provided key number 303 was not successful thenprocessing moves to step 612. At step 612 decryption of the secure data206 is attempted with each of the remaining untried keys 301 in the keyhistory 209 in turn until the correct key is identified and processingthen moves to step 609 and proceeds as described above. If at step 603the relevant resources are not available then processing moves to step613 where a resource error is reported to the VME 106 in the sourcedomain and processing then moves to step 611 and ends. If at step 604the key hash 302 is not present in the system key history 209 thenprocessing moves to step 614 where a key error is reported to the sourceVME 106. Processing then moves to step 611 and ends.

Embodiments of the invention enable a VME or hypervisor to allow anencryption key to be changed at any time since one or more old keys arepreserved for a period of time in the key history. As will be understoodby those skilled in the art, a system key change normally results in theidentification of data encrypted with an old key and the organisedre-encryption of this data with the new key. Normally, some operationson such data, such as migration, would be barred until it had beenre-encrypted. The functionality of the present invention enables suchoperations to be performed simultaneously. If for example a key changeoccurs during a migration, regardless of whether migrated data isencrypted using the new key or the old key, the old key is likely to bemaintained in the key history so as to enable the subsequent decryptionof the migrated data. In embodiments of the invention, during any givenmigration, key changes may occur in the source domain or the targetdomain or both without disabling the ability in either domain to decryptthe relevant data.

For example, a user may change the key on a source system A whilst amigration is taking place from system A to a target system B. A user mayalso initiate a migration of a virtual machine from system A to system Bwhilst a key change is in progress on B. A user may also initiate amigration of a virtual machine from system A to system B whilst a keychange is in progress on A. As part of the key change on system A thehypervisor will re-encrypt all of the virtual machine's data andmaintain knowledge of those successfully re-encrypted. As such thehypervisor will have a record of which virtual machine is using whichkey and may be arranged to either a) not bother re-encrypting themigrating virtual machine's data and migrate based on the old key, or b)migrate the virtual machine with the new key after successfulre-encryption. In any of the above cases the migration will only beallowed if both systems A and B contain the same key in their historythat was used to encrypt the migrated virtual machine's data.

In another embodiment of the invention an encryption key history isprovided for use when VMs with secure data are hibernated, that is, whenVMs are migrated from an active system to a storage device andvice-versa. In other words a VM may be hibernated on given system andmay subsequently be resumed on that system. At any time during a VMhibernation operation, whilst a VM is hibernated or during a VM resumeoperation, the encryption key history enables a change in the systemencryption key. Any hibernated VM can subsequently be resumed and itsencrypted data decrypted using the old key maintained in the encryptionkey history.

In a further embodiment of the invention an encryption key history isprovided for use in a high availability VM arrangement where, forexample, VMs are mirrored. In this embodiment, a VM running on system Ais capable of performing a live failover to system B if a problem occurson system A. The mirrored VM runs on system A and a dormant replica isprovided on system B and synchronised via regular checkpoints with theVM on system A. When failover occurs the dormant VM on system B resumesexecution at the last complete checkpoint. When the dormant VM wasinitially set up on system B, both systems A and B shared the same keyencryption key. Changes to the system key on either system A or B areallowed along with the consequent re-encryption of the relevant datawith the new key. This is possible because both systems A and B maintaina copy of the old key in the encryption key history. Therefore, when theVM fails over to system B the VM can decrypt its secure data with theold key maintained in the encryption history. In embodiments wherechanging the system key requires disrupting the VM in some way, forexample, by powering off, then it is also possible to allow the pairingbetween the mirrored VMs to remain unbroken by letting both the live anddormant VM keep their data encrypted with the old key. This avoidstearing down the pairing, changing the system key on B andre-establishing the mirrored pair, and assumes that B hasn't discardedthe old key used by the VM on system A.

In another embodiment, the VME is arranged to request all keys at oncefrom the key history instead of requesting each key, testing the key andif necessary requesting a further key as described above.

In a further embodiment, the relevant key number for a migrated VM isnot supplied to the target domain and the target domain interrogates thekey history in accordance with a predetermined method.

In another embodiment, the availability of a key from the source domainis not verified in the target domain prior to an operation such as amigration as described above with reference to the pre-migration keyhash check. In the present embodiment, the relevant key is assumed to beavailable in the target domain. As will be understood by those skilledin the art, this may result in the failure of the relevant operation ifthe key is not available and the decryption fails. In a furtherembodiment, instead of a key hash being provided to the target domain toestablish whether or not a given key is available, a portion ofencrypted test data is provided. Successful decryption of the test databy the target system indicates that it has access to the relevant key sothat migration can proceed.

In another embodiment, each entry in the key history comprises a countof virtual machines using the relevant key. This count enables unusedentries in the key history to be identified and removed eitherperiodically or on the introduction of a new key when the key history isfull. As will be understood by those skilled in the art, it is necessaryto ensure that old keys are not marked unused until any migratingvirtual machines using that key have successfully migrated.

As will be understood by those skilled in the art, any suitable way ofmaintaining usage information about old keys may be provided. Forexample, for each key in the key history a corresponding usage count orlist of references to VMs that currently use the key may be provided.When space is required in the key history, for the insertion of a newkey or as part of general key history maintenance or cleanup, the oldestkey having a zero usage count or no list of references will be selectedas the candidate for deletion.

As will be understood by those skilled in the art, any size ofencryption key history may be provided. For finite key histories any keychanges may be refused once the history is full. A full key history maybe managed automatically in accordance with any suitable clean-up methodor manually maintained by an administrator.

As will be understood by those skilled in the art, embodiments of theinvention may be provided in any suitable VME or hypervisor. Such VMEsor hypervisors may be arranged to run directly on the relevant computerhardware or run within an installed operating system. Where a hypervisorrun directly or natively on the computer hardware it effectivelyreplaces the operating system, which is thus no longer required.

As will be understood by those skilled in the art, the inventorycreation and pre-migration checks performed in embodiments of theinvention described above with reference to FIGS. 5 and 6 are commonlyperformed when migrating VMs in VMEs. The functionality of the toinvention may be incorporated with such standard pre-migration checks orbe provided as a distinct function.

It will be understood by those skilled in the art that the apparatusthat embodies a part or all of the present invention may be a generalpurpose device having software arranged to provide a part or all of anembodiment of the invention. The device could be a single device or agroup of devices and the software could be a single program or a set ofprograms. Furthermore, any or all of the software used to implement theinvention can be communicated via any suitable transmission or storagemeans so that the software can be loaded onto one or more devices.

While the present invention has been illustrated by the description ofthe embodiments thereof, and while the embodiments have been describedin considerable detail, it is not the intention of the applicant torestrict or in any way limit the scope of the appended claims to suchdetail. Additional advantages and modifications will readily appear tothose skilled in the art. Therefore, the invention in its broaderaspects is not limited to the specific details of the representativeapparatus and method, and illustrative examples shown and described.Accordingly, departures may be made from such details without departurefrom the scope of applicant's general inventive concept.

The invention claimed is:
 1. A method for migrating a virtual machinecontaining encrypted data from a source computer system to a targetcomputer system, the method comprising the following actions eachperformed by at least one of the source computer system and the targetcomputer system: maintaining, in said source computer system and saidtarget computer system, a respective historical record of encryptionkeys used on said source computer system and said target computer systemrespectively, each historical record containing a respective temporallysequenced plurality of encryption keys and, for each encryption key ofsaid temporally sequenced plurality of encryption keys, a respectiveusage count representing a respective number of virtual machines usingthe corresponding key; using the respective usage count of each key inthe historical record to determine when to delete the corresponding keyfrom the historical record in which it is contained; migrating datarepresenting a first virtual machine of multiple virtual machinesexecuting on said source computer system from said source computersystem to said target computer system, said data including at least somedata encrypted with a key of the plurality of keys in the historicalrecord of encryption keys in said source computer system; adding a newencryption key to at least one of the historical record of encryptionkeys in said source computer system and the historical record ofencryption keys in said target computer system, wherein said adding anew encryption key to at least one of the historical record ofencryption keys is performed concurrently with said migrating datarepresenting a first virtual machine; and determining, in said targetcomputer system, a key from among the plurality of keys in saidhistorical record of encryption keys in said target computer system tobe used in decrypting the data representing said first virtual machinewhich is encrypted, and decrypting the data representing the firstvirtual machine which is encrypted using the key so determined.
 2. Themethod according to claim 1 in which keys are maintained in eachhistorical record up to a predetermined maximum number after which theoldest key is discarded in response to the storing of a new key.
 3. Themethod according to claim 1, further comprising verifying that the keyused to encrypt the data representing the first virtual machine isavailable in said target computer system before performing saidmigrating data representing a first virtual machine executing on saidsource computer system from said source computer system to said targetcomputer system migrating.
 4. The method according to claim 3, whereinverifying that the key used to encrypt the data representing the firstvirtual machine is available in said target system comprisestransmitting a hashed value derived from said key from said sourcecomputer system to said target computer system, and verifying in thetarget system that the hashed value matches a key in its historicalrecord.
 5. The method according to claim 1, further comprising:determining in the target system whether the key used to encrypt datarepresenting the first virtual machine is the most recent key in thehistorical record in said target system; and responsive to determiningthat the key used to encrypt the data representing the first virtualmachine is not the most recent key, re-encrypting the data representingthe first virtual machine using the most recent key in the historicalrecord in said target system.
 6. The method according to claim 1,wherein at least three keys are maintained simultaneously in saidhistorical record.
 7. A first computer system, comprising: a processor;a memory; an operating system which provides a platform for executingone or more application programs; a virtual machine environmentapplication program executable on the first computer system, the virtualmachine environment supporting concurrent execution of a plurality ofvirtual machines, and containing: a first historical record ofencryption keys used for encrypting data in at least one of saidplurality of virtual machines said historical record containing atemporally sequenced plurality of encryption keys; a respective securedata manager for each of at least one of said plurality of virtualmachines, each secure data manager using at least one encryption keystored in said historical record to encrypt and decrypt data in thecorresponding virtual machine; and a migration manager for migratingvirtual machines between said first computer system and other computersystems, said migration manager performing a migration by: receiving,from a second computer system acting as a source computer system,migrated data representing a first virtual machine executing on thesecond computer system, said migrated data including at least some dataencrypted with a key of the plurality of keys in said first historicalrecord of encryption keys; wherein a new encryption key is added to atleast one of (a) said first historical record of encryption keys, and(b) a second historical record of encryption keys in said secondcomputer system, the new encryption key being added concurrently withsaid receiving, from the second computer system, migrated datarepresenting a first virtual machine; and determining a key from amongthe plurality of keys in said first historical record of encryption keysto be used in decrypting the migrated data representing said firstvirtual machine which is encrypted, and decrypting the migrated datarepresenting the first virtual machine which is encrypted using the keyso determined.
 8. The computer system according to claim 7 in which keysare maintained in said first historical record up to a predeterminedmaximum number after which the oldest key is discarded in response tothe storing of a new key.
 9. The computer system according to claim 7,wherein the migration manager further performs: verifying that the keyused to encrypt the data representing the first virtual machine isavailable in said computer system responsive to a request from thesource computer system before receiving the migrated data representing afirst virtual machine.
 10. The computer system according to claim 9,wherein verifying that the key used to encrypt the data representing thefirst virtual machine is available in said system comprises receiving ahashed value derived from said key from said source computer system, andverifying that the hashed value matches a key in said first historicalrecord.
 11. The computer system according to claim 7, wherein themigration manager further performs: determining in said computer systemwhether the key used to encrypt data representing the first virtualmachine is the most recent key in said first historical record; andresponsive to determining that the key used to encrypt the datarepresenting the first virtual machine is not the most recent key,re-encrypting the data representing the first virtual machine using themost recent key in said first historical record.
 12. The computer systemaccording to claim 7, wherein at least three keys are maintainedsimultaneously in said historical record.